How Pair Programming Really Works Programming

50 I E E E S O F T W A R E Pu b l i s h e d b y t h e I E E E C om p u t e r S o c i e t y 0 74 0 74 5 9 / 1 0 / $ 2 6 . 0 0 © 2 0 1 0 I E E E As a dictionary definition, I’d say that pair programming is a technique in which two people sit down, literally side by side, and write a program at the same computer. When Kent Beck originally coined the term, he described two programmers working at different levels of abstraction.1 Laurie Williams and Robert Kessler made this idea more concrete, using the metaphor of one programmer being the “driver” and the other the “navigator.”2 In this metaphor, the driver controls the keyboard and focuses on the immediate task of coding, and the navigator acts as a reviewer, observing and thinking about more strategic architectural issues. My own experience as a developer using pair programming is that it isn’t just a technique where one person programs and the other person watches. Both programmers work closely together, chatting the whole time, jotting down reminders of things to do, and pointing out pieces of code on the screen. (One of the clichés of pair programming is that if you’re doing it right, your screen should be covered with greasy finger-marks by the end of the day.) Programmers take turns at the keyboard, usually swapping over with a phrase like, “No, let me show you what I mean.” Jan Chong and Tom Hurlbutt confirmed this view of successful pair programming after spending several months on an ethnographic study of professional developers who use pair programming in their daily work.3 They found that programmers tended to work together on the same facet of a problem almost the whole time and swap between tactical and architectural levels as a pair. Similar ethnographic studies by Sallyann Bryant and her colleagues4 and Stephan Salinger and his colleagues further confirmed this.5 Of course, not all attempts at pair programming have been successful—Matt Stephens and Doug Rosenberg, for example, reported unfavorably on their experiences.6 However, what they described is a caricature of the drivernavigator metaphor, with one programmer firmly in control and the other sitting quietly, doing little. Such misunderstanding shows that we can’t take a claim that developers are pair programming at face value; they might not be doing what experienced and effective pair programmers actually do. P air programming has generated considerable controversy: some developers are enthusiastic about it, almost evangelical; others are dubious, even hostile. However, a large factor in this controversy is that programmers label a wide variety of practices under the “pair programming” umbrella. Thus, before our community can sensibly discuss how pair programming works, we first need to establish exactly what it is. Pair programming isn’t always successful, and recent studies cast doubt on the “drivernavigator” metaphor. Four mechanisms can improve pair programming performance. Stuart Wray, Royal School of Signals How Pair Programming Really Works pr o gr amming